程式源碼 (Source Code) 與目的碼（Object Code，註一）是軟體程式存在的兩種基本型態，前者指的是電腦程式可供後續增編修改的格式，有時可被直接執行，但多半時候必須經編譯或界定程序之後才能被執行，後者則是能夠直接供電腦機器判讀的執行檔格式，但因已經過編譯程序，故除非經過反組譯或是還原工程，否則一般人無法直接觀察目的碼，來了解該電腦程式的演算過程及運算邏輯 (algorithm)。一般來說，軟體程式可以擇一或是同時透過這兩種型態來被散布，就法律論理上，其在著作權法上是被視為是同一作品不同形態的表現，故其表現形式雖不同，但法律定位完全相同。過去電腦程式目的碼是不是能受到著作權法保障是有疑慮的，畢竟這樣的著作格式並不如同一般受著作權保護的客體：詩、詞、書、畫、文章、音樂、電影般，能被直接閱讀、聆聽、感受，和了解，不過美國於 ...

開放源碼（Open Source，註一）是現在許多人在接觸自由開源軟體時，第一個會接觸到的詞，它代表此類程式在散布時，皆能夠從散布者手上取得程式源碼。不過常見到的是，部份使用者會將這個詞，誤解為使用自由開源軟體所必須遵守的義務，認為一旦取得、持有自由開源軟體就必須主動公開手上所持有的程式源碼。其實開放源碼理想與提供源碼義務是兩個不同、但有所關聯的概念：開發者因為認同自由開源軟體理念，而主動公開其所撰寫的程式源碼，並授權給予他人來利用，所以他人才有機會以更深層的方式，利用到其所散布的自由開源軟體，這是屬於實踐開放源碼理想的過程；而當使用者取得自由開源軟體的程式源碼，部份條款要求其得在散布軟體的同時提供源碼給予後手，則是屬於履行授權義務的過程。本文以下將從自由軟體與四大自由談起，介紹相關的歷史背景與授權條款中提供源碼義務的內容，來說明開放源碼與提供源碼所代表的意義，以釐清兩個概念之間的關係。 ...

Mozilla 日前釋出了 Mozilla Public License (MPL) 的第二版。此授權協議距離上一次更新已超過 10 年時間，修改重點針對其他自由軟體與開放源碼授權提供更佳的相容性，可望為 Mozilla 專案擴展更廣泛的程式碼重復利用的選擇。 新版 MPL 歷經 21 個月的公開諮詢。其基礎是 1998 年制定的 MPL 1.0 版，該版本僅於 1999 年翻修過一次。MPL ...

... GPL 授權元件互動？原則上若是靜態連結的互動方式，則因為元件與元件之間傾向是高度相依的融合 (merge) 關係，此時整個軟體專案會被認定是 GPL 授權元件的衍生作品，而在後續散布時會被要求全部得依照 GPL 授權條款的方式，提供整體專案的程式源碼；而若是其他元件是以動態連結的機動方式呼叫 GPL 元件的功能表現，那麼這時候才會進入第三階段的判別流程，個案的去判別該 GPL 授權元件所提供的功能，在質的一方面，於整個軟體專案裡是否居於重要的核心地位？或是就量的方面，是否 ...

... (obligation) 來作為取得合法授權的交換條件！而 GPL 類別的授權元件，其最為人熟知與影響最為深遠的義務性要求，便是如果新的軟體專案內含 GPL 授權元件的程式碼，那原則上就是整個專案 (as a whole) 會被認定為 GPL 授權元件的衍生程式，從而這個軟體專案再釋出時，便必須依照 GPL 條款的各項授權規定，以提供後手程式源碼的方式來進行散布。GPL 授權條款這樣的要求相較於著作權法的預設，是大為擴張了法律原本對於衍生程式的抽象定義與解釋範圍，然而、以授權條款或是契約約定去補充法律規定之不足處，本就是私法行為下契約自由主義所容許的作為。但是、為了避免這樣的擴張機制引發過大的爭議與產生避用 ...

2003 年 3 月美國一家電腦公司 SCO 控告電腦界的藍色巨人 IBM（SCO Group v. International Business Machines, Inc.，註一），其指稱 IBM 在未經 SCO 的合法授權下，將 Unix 部份的程式源碼 (Source Code) 使用在 Linux 作業系統的撰寫中。這項指控的基礎在於，SCO 擁有 Unix 的著作權，SCO 並未事先授權 ...